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TITLE OF THE INVENTION 

DATA PROCESSING METHOD AND DATA PROCESSING DEVICE 

5 FIELD OF THE INVENTION 

The present invention relates to a data processing 
method and data processing device for registering meta-data 
in and distinguishing meta-data from data. 

10 BACKGROUND OF THE INVENTION 

Meta-data is "data about data, " and is used as data 

which explains binary data such as video data or audio data. 

However, when binary data and meta-data corresponding 

thereto exist in separate files, when moving or copying files, 
15 the user must simultaneously manage the binary data and the 

meta-data, which is very troublesome. 

For this reason, in order to simplify management of 

binary data and meta-data, various methods of writing binary 

data and meta-data have conventionally been proposed. This 
2 0 type of conventional art can be divided into methods which 

stipulate a new binary format, and methods of managing in 

a database . 

First, examples of methods which stipulate a new binary 
format include, for image data, Tiff, Exif , and Flashpix. 
25 Fig. 16 schematically shows a format which incorporates 
meta-data into binary data. Binary data is, for example, 
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image data. A typical method of incorporating meta-data into 
binary data, as shown in Fig. 16, is to provide in the header 
portion of the image data a domain for writing meta-data, 
into which the user writes the meta-data. Writing meta-data 
5 in this way facilitates data searching and classification. 
Further, since the meta-data is included in the binary data, 
both can be managed as a single file, making file management 
rg comparatively easier. 

y5 Next, a method of managing binary data and meta-data 

^ 10 in a database will be explained. Fig. 17 schematically shows 

rL e a method of managing binary data and meta-data in a database. 

y § 

y ' Methods like that shown in Fig. 17, which use a database, 

W etc. to manage binary data and meta-data existing as separate 

fy files, are widely used. These methods have the advantage that 

Q 15 existing binary data can be used as is in existing 

applications. 

It is also commonly known that a directory structure 
can be used in file management. Accordingly, when, for 
example, managing a large number of binary data files, all 

20 of the binary data files are usually not placed in a single 
directory, but a plurality of sub-directories are created, 
one for each group of binary data files sharing a certain 
affiliation or characteristic. In this case, the meta-data 
for all of the binary data files in a given sub-directory 

25 have an item in common. However, at present, each binary data 
file exists separately, and meta-data is managed by one of 
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the two methods discussed above. 

Both methods which stipulate a new format for writing 
meta-data and methods which manage meta-data using a database 
have their respective problems. 

First, when a new format for writing meta-data is 
stipulated, existing binary data must be converted into that 
new format, and then the meta-data written into the new format . 
Further, in order to use the meta-data in the new format for 
searching, applications compatible with the new format are 
necessary. In other words, the drawback of this method is 
that writing and using the meta-data require a very large 
number of steps and a special environment. In addition, in 
order to process binary data in the new format (in the case 
of image data, to replay the image, for example) , 
applications compatible with the new data format are 
necessary, and existing applications cannot be used. 

Moreover, since the method of writing the meta-data 
is uniquely determined by the new format, a further problem 
is that in order to prepare an application which uses 
meta-data in the new format, it is necessary to create new 
routines for searching the meta-data. In addition, the 
prescribed format must be changed in order to write meta-data 
in a new domain. 

On the other hand, when using a database to 
simultaneously manage binary data and meta-data, meta-data 
cannot be recorded or used without database software . Further, 




special software is also necessary to display recorded 
meta-data. In addition, when binary data is taken out of the 
database, it is not accompanied by the corresponding 
meta-data, and becomes binary data without meta-data. 

When using a directory structure to manage binary data 
files, as well, the meta-data for binary data files in a given 
directory exist for each binary data file, and are managed 
as separate files. Consequently, even when a plurality of 
binary data files share an item in common, each binary data 
file is managed independently, thus increasing the data 
quantity of meta-data which must be managed. Further, when 
changing an item in common, meta-data for each binary data 
file changed must also be changed. 

H = 

y = 

S. 15 SUMMARY OF THE INVENTION 

The present invention was created in view of the 
foregoing problems relating to writing and searching 
meta-data, and it is an object hereof to enable registration 
of meta-data in directory data without influencing existing 
20 applications. 

Another object of the present invention is to use a 
typical data writing language to write meta-data, thus 
enabling the use of existing tools compatible with typical 
data writing languages, and facilitating the development of 
25 compatible applications. 

A further object of the present invention is to enable 
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meta-data written in directory data to be extracted therefrom 
and provided for processing such as searching, reference, 
and modification. 

A further object of the present invention is to 
register meta-data in a directory, thereby contributing to 
simplification of management of meta-data and reduction of 
data quantity thereof. 

A further object of the present invention is to enable 
simple attachment of meta-data to data files grouped by a 
certain affiliation or characteristic and managed by a 
directory. 

In order to attain the foregoing objects, in one 
embodiment of the present invention, meta-data is registered 
in directory data . By registering meta-data in directory data , 
it becomes unnecessary to attach meta-data to each of the 
files under that directory, and change of the contents 
thereof is also simplified. 

A further object of the present invention is to prevent 
meta-data registered in a directory from being lost or wasted 
when a file is moved or copied from that directory. 

A further object of the present invention is to enable 
suitable meta-data to be attached to a directory even when 
meta-data is already registered in each binary data. 

A further object of the present invention is to 
expedite searching by extracting suitable meta-data from a 
data file with meta-data registered therein, and registering 
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that meta-data in directory data. 

A further object of the present invention is to simply 
group data files in directories by certain affiliations or 
characteristics . 

Other features and advantages of the present invention 
will be apparent from the following description made in 
conjunction with the accompanying drawings, in which like 
reference symbols designate the same or similar members 
throughout the figures thereof. 



BRIEF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, which are incorporated in 
and constitute a part of the Specification, illustrate 
embodiments of the present invention and, together with the 
15 description, serve to explain the principles of the 
invention. 

Fig. 1 is a block diagram showing the structure of a 
data processing device according to a first embodiment of 
the present invention. 
2 0 Fig. 2 is a flow chart explaining meta-data 

registration processing according to the first embodiment. 

Fig. 3 is a drawing explaining registration of 
meta-data in directory data according to the first 
embodiment . 

2 5 Fig. 4 is a flow chart showing steps for distinguishing 

and extracting registered meta-data according to a second 
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embodiment of the present invention. 

Fig. 5 is a flow chart explaining the details of 
processing for distinguishing meta-data according to the 
second embodiment . 
5 Fig. 6 is a drawing showing an example of data structure 

of directory data with XML data registered therein as 
meta-data . 

ra Fig. 7 is a drawing explaining an example of a directory 

-J3 structure according to the second embodiment. 

iff 

Ul 10 Fig. 8 is a flow chart explaining processing for 

£n revising directory data according to the second embodiment, 

yl Fig. 9 is a flow chart showing a method of registering 

Q meta-data in binary data according to a third embodiment of 

fj the present invention. 

15 Fig. 10 is a flow chart explaining a method of 

" determining whether meta-data is registered in binary data 

according to the third embodiment . 

Fig. 11 is a drawing showing an example of data 
structure of binary data with meta-data registered therein 
2 0 according to the third embodiment. 

Fig. 12 is a drawing explaining an example of a method 
for comparing and synthesizing meta-data and directory data 
according to the third embodiment. 

Fig. 13 is a flow chart showing a method of registering 
2 5 automatically generated directory meta-data in directory 
data according to a fourth embodiment of the present 
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invention . 

Fig . 14 is a flow chart showing a method of 
automatically generating directory meta-data according to 
the fourth embodiment . 
5 Fig. 15 is a drawing showing an example of automatic 

generation of directory meta-data from a list of meta-data 
according to the fourth embodiment . 

Fig. 16 is a drawing schematically showing a format 
which incorporates meta-data into binary data . 
10 Fig. 17 is a drawing schematically showing a method 

for managing binary data and meta-data in a database. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the present invention will 
15 now be described in detail with reference to the accompanying 
drawings . 

[First Embodiment] 

Fig. 1 is a block diagram showing the structure of a 
data processing device according to the first embodiment of 

2 0 the present invention. In Fig. 1, 100 is a reading section, 
which reads an image using a scanner, for example. 101 is 
an input section, which inputs instructions from the user, 
data, etc., and which includes a keyboard, a pointing device, 
etc. 102 is a storage section, which stores binary data, 

2 5 meta-data, etc. in a directory structure. A hard disk is 
typically used as the storage section 102. 103 is a display 
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section, which displays binary data accumulated in the 
storage section 102, and displays image data read by the 
reading section 100. A CRT, liquid crystal display device, 
etc. is typically used as the display section 103. 

104 is a CPU, which is involved in all processing of 
the respective structures above, and a ROM 105 and a RAM 106 
provide to the CPU 104 programs, data, and/or operating 
domains necessary in this processing. Here, a control program 
for realizing the processing steps of the present embodiment, 
to be explained below with reference to the flow chart in 
Fig. 2, is also stored in the. ROM 105. A structure in which 
this control program is stored in the storage section 102 
and loaded into the RAM 106 for execution by the CPU 104 is 
also possible. 

Incidentally, a data processing device according to 
the present embodiment is provided with various structural 
elements in addition to those discussed above, but these are 
not the principal object of the present invention, and 
accordingly explanation thereof will be omitted here. 

The following will explain processing for registering 
meta-data in directory data using a data processing device 
structured as above. Fig. 2 is a flow chart explaining 
meta-data registration processing according to the present 
embodiment . 

In Fig. 2, first, in step S301, directory data of a 
directory indicated by the user is read into memory (into 



the RAM 106) . This is accomplished by , for example, inputting 
the name of a desired directory through the keyboard, or 
indicating the directory using a pointing device (such as 
a mouse) . Next, in step S3 02, an XML file which records 
meta-data, indicated by the user, is read into memory (into 
the RAM 106) . The XML file is also indicated by inputting 
the file name through the keyboard, indicating a 
corresponding icon using a pointing device (such as a mouse) , 
etc . 

Next, in step S3 03, it is investigated whether the XML 
file recording meta-data is XML data of the proper format. 
In making this determination of proper format, it is checked 
whether the format for writing an XML file is satisfied (for 
example, whether or not the brackets at the left and right 
of each tag form pairs, whether the form of tagging is correct, 
etc. ) . This determination of whether or not the XML data has 
the proper format may also include a check of whether it is 
valid XML data. Here, this determination of whether it is 
valid XML data may be accomplished by, for example, checking 
whether or not the XML data is written in accordance with 
a schemer such as DTD (Document Type Definition) . 

If it is determined in step S3 03 that the XML data does 
not have the proper format, processing proceeds to step S3 07 . 
In step S307, a message to the effect that there was an error 
in the XML data is displayed on the display section 103, and 
processing ends. 
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If, on the other hand, it was determined in step S3 03 
that the XML file was XML data in the proper format, processing 
proceeds to step S3 04 . InstepS304, the meta-data is appended 
to the end of the directory data read into memory in step 
5 S3 01, thereby registering the meta-data. Then, in step S30 6, 
the directory data registering the meta-data is outputted, 
and processing ends. By means of the output in step S3 06, 
directory data with meta-data attached thereto, having the 
data structure shown in Fig. 3, is stored in the storage 
10 section 102 as a single directory data file. 

Fig. 3 is a drawing explaining registering of meta-data 
in directory data according to the present embodiment . As 
shown in Fig. 3, meta-data written in XML data format is 
appended to the end of the directory data (in the present 
15 example, after the identifier <EOF> indicating the end of 
S3 the directory data) . In this way, the meta-data can be 

registered in the directory data without influencing other 
applications. Specifically, in referring to directory data, 
typical applications only use data from the beginning of the 
20 directory data to the final identifier, and thus the 
meta-data appended thereafter does not affect the 
application. 

Further, since the meta-data is written in XML format, 
by extracting this XML data portion, it is possible to add 
25 to, change, or refer to the meta-data using tools which 
understand XML data. Thus the present invention is superior 
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in wide applicability. Incidentally, extraction of an XML 
data portion will be explained in detail in the second 
embodiment below . 

As discussed above, in the present embodiment, by 
5 writing meta-data in XML format and appending this XML data 
to the end of directory data, meta-data can be registered 
in existing directory data, without influencing existing 
applications . 

O 

jj* [Second Embodiment] 

fL; 10 The first embodiment above explained a method of 

2? registering meta-data in directory data to create a directory 

y 

z.} data file. The present second embodiment will explain 

^ processing for distinguishing whether or not meta-data is 

=F registered in a directory data file, and when it is registered, 

m 

CP 15 for extracting the meta-data. Here, a data processing device 

Q according to the present second embodiment is structured as 

that of the first embodiment above, and accordingly 

explanation thereof will be omitted. 

The following will explain determination of whether 
20 meta-data registered in the manner explained in the first 
embodiment above is present in the directory data file of 
an indicated directory, and operations for extracting the 
registered meta-data. Fig. 4 is a flow chart showing steps 
for distinguishing and extracting registered meta-data 
25 according to the present second embodiment. Incidentally, 
in the present embodiment, the extracted meta-data is 
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displayed on the display section 103, but the form of output 
is not limited to this. It will be evident to one skilled 
in the art that other structures are also possible, such as 
one which provides the extracted meta-data for editing or 
5 search processing. 

As shown in Fig. 4, first, in step S501, the user indicates 
a directory data file for which it is to be determined whether 
or not meta-data is registered therein, i.e., data for 
3 processing. In step S501, indication of the data for 

yf 10 processing is accomplished by, for example, inputting the 

m 

CO file name of a directory data, file through the keyboard, or 

y -s 

Lff indicating a corresponding icon using a pointing device (such 

a as a mouse) . 

jf Next, in step S502, it is determined whether or not 

15 meta-data written in the XML format is registered in the data 
of the indicated directory data file. Here, the details of 
the determination processing in step S502 will be explained 
with reference to the flow chart in Fig. 5 and the explanatory 
drawing in Fig. 6. Fig. 5 is a flow chart explaining the 
20 details of processing for distinguishing meta-data according 
to the present embodiment. Further, Fig. 6 is a drawing 
showing an example of data structure of directory data which 
registers XML data as meta-data. 

As was explained in the first embodiment above, the 
25 data structure of a directory data file (data for processing) 
with XML data as meta-data registered therein, is as shown 
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in Fig. 6. Accordingly, distinguishing the presence or 
absence of meta-data is performed as follows. 

As shown in Fig. 5, first, in step S601, the entirety 
of the data of the directory data file (the entirety of the 
data for processing) indicated in step S501 is read into 
memory (into the RAM 106) . Since the data outputted in step 
S3 06 in the first embodiment above is managed as a single 
file, the entirety of the data can be read out using a file 
manag i ng sy s t em . 

Next, in step S602 , it is checked whether the character 
string M </PhotoXML> M is present at the end of the data read 
in step S601. If this character string is not present, 
processing proceeds to step S605. 

If the character string "</PhotoXML>" was present at the end 
of the data for processing, processing proceeds to step S603, 
where it is determined whether the character string 
"</PhotoXML>" is preceded by a character string " <PhotoXML> " . 
If in step S603 the character string " <PhotoXML> " was found, 
processing proceeds to step S604, where it is concluded that 
meta-data is registered in the data for processing, and 
processing ends. If, on the other hand, the character string 
,, <PhotoXlyIL> ,, was not found, processing proceeds to step S605, 
where it is concluded that no meta-data is registered in the 
data for processing. In other words, if the character string 
"</PhotoXML>" is not found in step S602, or if the character 
string ,, <PhotoXML>" is not found in step S603, processing 
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proceeds to step S605, where it is concluded that no meta-data 
is registered in the data for processing. 

Incidentally, in step S603, after finding the character 
string "<PhotoXML>" , it is possible to confirm whether the 
data bracketed by the two foregoing character strings is 
written in proper XML format. Further, in this case, it is 
also possible to perform determination of whether the data 
is valid XML data. Here, this determination of proper format 
and of valid data are as explained in the first embodiment 
above (step S3 03) . 

The following explanation returns to the flow chart 
in Fig. 4. When it was concluded in the processing shown in 
the flow chart in Fig. 5 that meta-data is registered in the 
data for processing, processing proceeds to step S503 . In 
step S503, based on the XML data bracketed by the character 
strings M <PhotoXML>" and "</PhotoXML>" , the meta-data is 
displayed on the display section 103, and processing ends. 
If, on the other hand, it was determined in step S502 that 
there is no meta-data registered in the data for processing, 
processing ends. 

As explained above, in the present embodiment, it is 
possible to distinguish directory data with meta-data 
recorded therein from normal directory data based on rules 
for writing XML data, and, when directory data recording 
meta-data is distinguished, to display the meta-data. 

In other words, in the present embodiment, it is 
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possible to distinguish directory data which registers 
meta-data from directory data which does not register 
meta-data, and to extract the registered meta-data. 
Accordingly, if an existing data writing language is used 
5 for the meta-data, it is possible to, for example, edit, refer 
to, or search the meta-data using existing tools for that 
data writing language, thus saving the effort of developing 
new tools. 

2 Next, a method of storing meta data for binary data 

In 

jjl 10 files stored by directory will be explained m concrete terms 

S= with reference to Fig. 7. For ease of explanation, assume 

=L; that, as shown in Fig. 7, a root directory Directory 1 contains 

three sub-directories Directory 2, Directory 3, and 
Directory 4, each of which contains binary data files. 
15 In such a case, if meta-data is registered in the 

directory data of each directory, common meta-data is stored 
for the Binary Data Files 2-1 through 2-3 in Directory 2, 
common meta-data is stored for the Binary Data Files 3-1 and 
3-2 in Directory 3, and common meta-data is stored for the 
20 Binary Data Files in Directory 4. 

If the binary data files contain, say, image data 
recorded using a digital camera, a simple example of 
meta-data would be information indicating that the binary 
data in Directory 2 was recorded on March 10, and the binary 
25 data in Directory 3 was recorded on March 11. Alternatively, 
it is also possible to divide into directories based on some 
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sort of affiliation, such as "Scenery" or "People." In any 
case, the items, contents, etc. stored in the meta-data can 
be determined by the manner in which data files are divided 
at the time of creating the sub-directories. 
5 In the case above, meta-data is not stored in each 

binary data file, but in the directory data of each sub- 
directory. Accordingly, an application reading a binary data 
file will read out the meta-data attached to the directory 
p the binary data file belongs to, and process this as meta-data 

UT 10 for the binary data file. 

y = 

m For example, in order to search for a binary data file 

fff 

by a certain item stored in the meta-data, in the present 
embodiment, since the meta-data attached to the directory 
data is effective for all of the binary data files belonging 
15 to that directory, it is sufficient to merely search the 
directories, making it possible to perform search processing 
rapidly. 

Incidentally, in the foregoing explanation, the data 
stored in the directories was binary data, but it may of course 
2 0 be any type of data. 

[Revision of Directory Data by File System] 

When files are added to or removed from a directory 
the file system revises the directory data in accordance with 
this processing. However, if the directory data is revised 
2 5 with the meta-data attached, the meta-data is destroyed. 
Accordingly, in order to handle directory data to which 
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meta-data has been attached as explained in the first 
embodiment above, slight changes to the file system are 
necessary. The following will explain processing for 
revision of directory data by the file management system. 

Fig. 8 is a flow chart explaining processing for 
revising directory data according to the present embodiment. 
If a file is added to the directory, or if a file in the 
directory is revised or deleted, the processing shown in Fig. 
8 is carried out. 

First, in step S701, the directory data file of the 
directory in question is read out. Then, in step S702, it 
is determined whether meta-data is attached to the directory 
data. This determination can be performed according to the 
steps shown in Fig. 5 discussed above. Then, if it is 
determined that meta-data is registered in the directory data, 
processing proceeds to step S703. 

In step S703, the detected meta-data is separated from 
the directory data and stored out of harm 1 s way in a separate 
memory area. Next, in step S7 04, the directory data left after 
separation of the meta-data is edited in the same manner as 
conventionally. Then, after editing of the directory data 
is completed, in step S705, the meta-data separated from the 
directory data in step S7 03 is re-appended to the end of the 
revised directory data. If on the other hand it was found 
in step S7 02 that there is no meta-data registered in the 
directory data, processing proceeds to step S706, and the 
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directory data is revised straightaway. 

In the foregoing processing, processing for revising 
the directory data in steps S704 and S706 may be equivalent 
to processing executed by conventional file managing systems . 
5 Accordingly, it will be evident to one skilled in the art 
that the required conversion of conventional file management 
systems is not a major matter, and that with only minor changes 
they can be enabled to handle directory files according to 
the present embodiment . 
10 As discussed in the first and second embodiments above, 

2 in the present invention, since meta-data is registered in 
Ul directory data, meta-data can be registered and managed by 

3 directory. 

Further, with the present invention, by appending 
gi 15 meta-data to the end of conventional directory- data, 

S meta-data can be registered in directory data without 

affecting existing applications. 

Moreover, in the present invention, meta-data can be 
extracted from directory data recording meta-data and 
20 provided for processing such as searching, reference, change, 
etc. Accordingly, by using a typical data writing language 
to write the meta-data, existing tools for that data writing 
language can be used, thus facilitating the development of 
compatible applications . 
25 In addition, in the present invention, registering 

meta-data in a directory can facilitate meta-data, and can 
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help reduce data quantities. Consequently, when, for example, 
searching binary data for a given item included in the 
meta-data, only the directories need be searched, and the 
search can be performed rapidly. Further, to change a value 
5 in a given item included in the meta-data, it is not necessary 
to change meta-data for each binary file; the meta-data for 
all binary files in a given directory can be changed by 
changing only the meta-data attached to the directory data. 
*B ■ Consequently, meta-data can be changed rapidly. Moreover, 

yi 10 since meta-data common to a plurality of binary files 

CO 

m belonging to a given directory can be managed as a single 

J meta-data, data quantity can be reduced. 

^ [Third Embodiment] 

J! The first and second embodiments above discussed 

i y 

15 registration of meta-data in directory data. If meta-data 
W is registered in directory data, it becomes unnecessary to 

attach meta-data to each file in the directory, and it is 
also easier to change the contents of the meta-data. However, 
if files are moved or copied from the directory, the meta-data 

20 registered in the directory may be lost, thus wasting the 
meta-data registered in the directory. In the present third 
embodiment, in order to resolve the foregoing problem, when 
binary data belonging to a directory is copied or moved 
outside the directory, meta-data is registered in that binary 

25 data. Here, a data processing device according to the present 
third embodiment is equivalent to that of the first 
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embodiment (Fig. 1), and accordingly explanation thereof 
will be omitted here. 

A method of registering meta-data in binary data 
according to the present third embodiment will now be 
explained with reference to the flow chart in Fig. 9. In the 
flow chart in Fig . 9 , when binary data belonging to a directory 
is copied or moved outside the directory, meta-data is 
registered in that binary data. 

First, in step S13 01, a user indicates a binary data 



10 file in the directory to be copied or moved to another 
directory. The processing to be discussed below is performed 



zj on the copy of the binary data (not on the original binary 

^ data) when the operation is copying, and on the binary data 

jP after being moved, when the operation is moving. Next, in 

En 15 step S13 02, it is determined whether the directory to which 

Q the indicated file belongs registers directory meta-data 

like that explained in the first and second embodiments above . 
This determination of whether or not directory meta-data is 
registered in the directory is performed as was explained 
20 above with reference to Figs. 5 and 6. 

If the result of the determination in step S1302 is 
that there is directory meta-data registered in the directory, 
processing proceeds to step S1303, and if there is no 
directory meta-data, processing proceeds to step S1304. In 
25 step S13 04, since there is no meta-data registered in the 
directory, the indicated binary data is copied (or moved) . 



- 21 - 



When, on the other hand, there is directory meta-data, 
it is determined in step S13 03 whether there is meta-data 
registered in the binary data indicated in step S13 01. 
Processing for determining whether meta-data is registered 
in the binary data will be explained with reference to Figs. 
10 and 11. Fig. 10 is a flow chart showing processing for 
determining whether meta-data is registered in the binary 
data, and Fig. 11 is a drawing explaining registering of 
meta-data in binary data according to the present embodiment. 

Binary data with meta-data registered therein is made 
up of the parts shown in Fig. 11. Accordingly, in order to 
distinguish the presence or absence of meta-data, in Fig. 
5, first, in step S1601, the entirety of the indicated binary 
data is read into memory. Next, in step S1602, it is checked 
whether the character string "</PhotoXML> " is present at the 
end of the binary data read into memory. If this character 
string is present, processing proceeds to step S1603, where 
it is checked whether a character string ,, <PhotoXML>" is 
present before the character string "</PhotoXML>" . If this 
character string is also present, processing proceeds to step 
S1604, where it is concluded that meta-data is registered 
in the binary data. 

On the other hand, if it is judged in step S1602 that 
the character string "</PhotoXML>" is not present, or if it 
is judged in step SI 6 03 that the character string 
"<PhotoXMLi>" is not present, then processing proceeds to step 



S1605, where it is concluded that no meta-data is registered 
in the binary data . 

If it is determined by the foregoing determination 
processing that there is no meta-data registered in the 
5 binary data, processing proceeds to step S1308. When 
processing has proceeded to step S13 08, it means that 
directory meta-data is registered in the directory, but no 
meta-data is registered in the binary data. Accordingly, the 
directory meta-data is registered in the binary data, the 

10 binary data is copied (or moved) , and processing ends. Here, 
meta-data is registered in the binary data by the same method 
as that for registering meta-data in directory data explained 
in the first embodiment above. In other words, data having 
the form shown in Fig. 11 is generated by appending the 

15 meta-data to the end of the binary data. 

If, on the other hand, it was determined in step S1303 
that meta-data is registered in the binary data, processing 
proceeds to step S13 05. In step S13 05, the directory 
meta-data registered in the directory and the meta-data 

20 registered in the binary data are compared. Then, in step 
S13 06, meta-data is prepared which, as a result of the 
comparison in step S1305, includes all of the directory 
meta-data and binary data meta-data. 

Here, processing for generating the meta-data in step 

25 S13 06 will be explained in detail. As shown in Fig. 12, 
directory meta-data 1801 and meta-data 1802 are combined to 
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create meta-data 1803, which includes all the contents of 
both meta-data. 

The meta-data prepared as above is then newly- 
registered in the binary data, which is then copied (or moved) , 
and processing ends. 

As discussed above, in the present embodiment, when 
copying or moving binary data belonging to a directory, 
directory meta-data registered in the directory is 
registered in the binary data as meta-data, and thus even 
if some of the files in a directory are moved elsewhere, the 
meta-data is not lost. 

Further, even when meta-data is already registered in 
the binary data, this meta-data can be synthesized with the 
directory meta-data, and thus meta-data combining the 
directory meta-data and the meta-data can be registered in 
the binary data. 

As is clear from the foregoing explanation of the 
present embodiment, in the present invention, directory 
meta-data written in the same data writing language as the 
directory data is registered in the binary data, and thus 
it is possible to copy or move the binary data while preserving 
the directory meta-data information. In addition, since the 
meta-data is written in a data writing language, existing 
tools for that data writing language can be used as is, thus 
saving the effort of developing new tools. 
[Fourth Embodiment] 



In cases when binary data already has meta-data, the 
present fourth embodiment enables registering of suitable 
meta-data in directory data. Here, a data processing device 
according to the present fourth embodiment is equivalent to 
that of the first embodiment (Fig. 1), and accordingly 
explanation thereof will be omitted here. A method of 
generating suitable meta-data from binary data in a directory 
will now be explained with reference to the flow chart in 
Fig. 13. 

In Fig. 13, first, in step S2301, the user indicates a desired 
directory (a directory for which meta-data is to be generated 
and to which the meta-data is to be attached) . Then, in step 
S2302, one of the data files in that directory is selected, 
and it is determined whether or not meta-data is registered 
in that file. The steps for distinguishing the presence or 
absence of meta-data are as explained above with reference 
to Figs. 10 and 11. 

When there is meta-data registered in the binary data, 
processing proceeds to step S2303, where the file name of 
the binary data registering meta-data, and the meta-data are 
added to a list 1 in memory. On the other hand, if in step 
S2302 there was no meta-data registered in the binary data, 
processing proceeds to step S2304. In step S2304, the file 
name of the binary data not registering meta-data is added 
to a list 2 in memory. The foregoing processing is executed 
for all of the files in the directory (step S2305) . 



Next, in step S23 06, directory meta-data is generated from 
list 1, which records the file names of binary data 
registering meta-data, and those meta-data. Processing for 
generating directory meta-data from list 1 will be explained 
5 below with reference to Figs. 14 and 15. Fig. 14 is a flow 
chart explaining steps for generating directory meta-data 
in step S23 06, and Fig. 15 is a drawing explaining generation 
of directory meta-data in step S2306. 

In step S2401, it is checked whether all of the meta-data 
10 recorded in list 1 share one or more meta-data item(s) in 
common. Here, if all of the meta-data have one or more 



00 

]5 meta-data item(s) in common, processing proceeds to step 



~ S2404, where the meta-data item(s) in common is /are extracted, 

^ directory meta-data is generated using the extracted 

2 15 meta-data item (s) , and processing ends . This processing will 

O now be explained with reference to Fig. 15. From list 1 (501) , 

it can be seen that meta-data is attached to the three image 
files img001.jpg, img002.jpg, and img003.jpg (filenames are 
the character strings bracketed by <Filename> and 
2 0 </Filename>, and meta-data are the data bracketed by 
<PhotoXML> and </PhotoXML>) . Extracting the meta-data items 
shared by the three data files listed in list 1 (501) and 
generating directory meta-data therefrom yields the 
directory meta-data (502) . 
2 5 If, in step S2401, there were no meta-data items shared by 
all of the meta-data, processing proceeds to step S2403, 
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where directory meta-data is generated using the meta-data 
item(s) shared by the most meta-data. Then, in step S2404, 
a list 3 is generated, which lists the names of data files 
registering meta-data which does not include the meta-data 
item(s) included in the directory meta-data. Then, in step 
S2405, the file names listed in list 3 and their meta-data 
are deleted from list 1. 

Then, returning to Fig. 13, in step S2307, a new directory 
is generated, and all of the data files recorded in list 1 
are moved to this new directory. Incidentally, in step S2307, 
the new directory is given a- suitable name taken from the 
directory meta-data. Next, in step S2308, it is determined 
whether list 3 has been generated; if it has been generated, 
processing proceeds to step S2309, but if not, step S2309 
is skipped. In step S2309, the data files recorded in list 
3 are moved to a directory named "MetaMisc. " Finally, in step 
S2310, directory meta-data is registered in the new directory 
generated in step S2307, and processing ends. Here, the 
method of registering the meta-data in the new directory is 
as explained in the first embodiment above, and has a data 
structure like that shown in Fig. 6. 

The foregoing processing makes it possible to automatically 
generate directory meta-data from the data files in the 
directory^ and to register this meta-data in the directory. 
As discussed above, in the present embodiment, directory 
meta-data can be automatically generated from data files in 
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a directory, thus making it easy to register directory 
meta-data in the directory. Even when there are no meta- 
data items in common, by automatically generating directory 
meta-data from the binary data files in the "MetaMisc" 
directory, new directories and directory meta-data therefor 
can be repeatedly generated automatically. 

Incidentally, in the present embodiment, when all of 
the data files in the indicated directory are listed in list 
1 (i.e. , when all of the data files in the directory register 
meta-data, and all of the meta-data share one or more 
meta-data item(s) in common) , the meta-data generated may 
be registered in the directory data of the indicated 
directory, without generating a new directory. 

As is clear from the foregoing explanation of the 
fourth embodiment, the present invention makes it possible 
to automatically generate directory meta-data from binary 
data. Further, attaching meta-data to the directory enables 
high-speed searching. Moreover, since the meta-data is 
written in an existing data writing language, existing tools 
for that data writing language can be used as is, thus saving 
the trouble of developing new tools. 

Incidentally, in each of the foregoing embodiments, 
the meta-data was XML data, but there is no limitation to 
this . For example, it may be written in a data writing language 
such. as SGML or HTML. Further, the data of the files in each 
directory may be binary data such as still image data, dynamic 
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image data, or audio data, or any other form of data. 

The present invention may be applied to a system made 
up of a plurality of devices (such as host computer, interface 
device, reader, printer, etc.)/ or to a single device (such 
as a copy machine, facsimile, etc.) . 

Further, the objects of the present invention may of 
course also be attained by supplying a system or a device 
with a memory medium recording the program code of software 
for realizing the functions of the foregoing embodiments, 
and using a computer (or CPU or MPU) of the device or system 
to read out and execute the program code stored in the memory 
medium . 

In such a case, the program code itself, read out from 
the memory medium, realizes the functions of the embodiments 
discussed above, and the memory medium recording that program 
code structures the present invention. 

The memory medium for supplying the program code may 
be a floppy disk, hard disk, optical disk, magneto-optical 
disk, CD-ROM, CD-R, magnetic tape, non-volatile memory card, 
ROM, etc. 

In addition, it goes without saying that the scope of 
the present invention covers not only a case in which the 
functions of the foregoing embodiments are realized by 
executing the program code read out by a computer, but also 
a case in which, based on the instructions of the program 
code, an OS (operating system) operating in the computer 



performs part or all of the actual processing, and this 
processing realizes the functions of the foregoing 
embodiments . 

Furthermore, it goes without saying that the scope of 
the present invention also covers a case in which the program 
code read out from the memory medium is written into the memory 
of an expansion board or expansion unit inserted into or 
connected to the computer, and, based on the instructions 
of the program code, a CPU, etc. of the expansion board or 
expansion unit performs part or all of the actual processing, 
and this processing realizes the functions of the foregoing 
embodiments . 

As many apparently widely different embodiments of the 
present invention can be made without departing from the 
spirit and scope thereof, it is to be understood that the 
invention is not limited to the specific embodiments thereof 
except as defined in the claims. 
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